SERVICE CONTROL NETWORK SYSTEM 



FIELD OF THE INVENTION 



The present invention generally relates to a service 



5 control network system, and more particularly a service 
control network system capable of providing for each user 
a service on an application-by-application basis. Also, 
the present invention relates to a server managing service 
information in the service control network system and a 
10 service execution unit providing the service for a terminal 
unit. 



15 communication service customized for each user, there has 
been disclosed a method for reducing the load of a service 
control program in a service control unit caused by 
transferring the information between service control units , 
by reducing an amount of individual user information to 

20 be maintained in the service control program. (For example, 
refer to the patent document 1.) 

Also, there has been disclosed a method for providing 
a service customized for each user based on a processing 
policy provided in a service control unit which stores each 

25 user's condition and the processing policy set for 
individual users having the opposite user requesting for 
communication with a user , a condition of the user requested , 



BACKGROUND OF THE INVENTION 



As a conventional technique for providing a 
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and a process corresponding to a request content. (For 
example, refer to the patent document 2.) 

Meanwhile, in recent years, there has been proposed 
a concept of Policy-Based Networking (PBN), which is a 
5 framework for controlling an IP network. In the PBN, a policy 
server sets network operation policies into a network 
apparatuses. By referring to the policies, the network 
apparatuses perform network services so as to meet QoS 
(Quality of Services) requirement, etc. 

10 However, in view of setting a policy in each mobile 

terminal (user), it is required to set the policy to the 
entire apparatuses having possibilities of accommodating 
such a mobile terminal , which results in an increased amount 
of policy setting processing throughout the network. 

15 Further, in order to apply the information notified in the 
PBN to the individual basic services specified by the Mobile 
IP, etc. , it is necessary to make a concrete specification 
to be applied to each service, as well as studies for 
implementation. 

20 In order to avoid the aforementioned increase > in ; the 

amount of policy setting processing, there may be 
considered a method by the use of a connection 
authentication procedure or a location registration 
procedure in a mobile protocol (for example, Mobile IP) 

25 performed by a user host terminal against the network. 
According to such a method, service control information 
for each user is included in a message transferred between 
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the apparatuses having the host authentication procedure. 
This service control information is distributed to an edge 
router ( router positioned in the edge zone of a core network ) . 
The edge router refers to the acquired service control 
5 information, and controls the service behavior based on 
the acquired service control information. 

However/ such the service control performed by the 
edge router is suitable for a service closed within the 
network layer (the layer three in the OSI reference model, 

10 or the IP layer). 

As compared to the service performed in the 
above-mentioned layer, a service performed in the layer 
higher than the layer four, such as the layer seven (or 
the application layer), has features described below. 

15 (Hereinafter the service is referred to as 'high-layer 
services ' . ) 

Generally, the high-layer services is not dependent 
on a packet transfer path, etc. Such a service is not always 
appropriate to be performed in the edge zone of the core 

20 : network-. ^ : < • , : , .♦. 

Also, in general, it is not possible to identify whether 
or not the high-layer services is requested at the time 
of authenticating an access from a user terminal. For 
example, as forauser who started to use in a public wireless 

25 LAN service area, it is not possible to identify whether 
the userwilluse the IP telephone service first , or instead, 
access the Web service. 
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[Patent Document 1] 

The official gazette of Japanese Unexamined Patent 
Publication Number Hei-8-256367 (pages 3 - 5, and Fig. 1) 
[Patent Document 2] 
5 The PCT Gazette of International Publication Number 

00/19326 

SUMMARY OF THE INVENTION 
The present invention has been invented in 

10 consideration of the aforementioned background. It is an 
object of the present invention to provide a customized 
higher-layer services on a user^by-use basis , -as well as 
on an application-by-application basis. 

In order to achieve the above-mentioned object, a 

15 service control network system in accordance with the 
present invention includes; a service execution unit 
providing a service to a terminal unit ; and a server managing 
service information specifying the service to be provided 
to the terminal unit. The service execution unit further 

20 includes; a request transmission section transmitting to 
the server a reference request for the service information 
corresponding to either a service initiation request or 
a registration request, on receipt of the service 
initiation request or the registration request from the 

25 terminal unit; and a service provision section providing 
the service to the terminal unit based on the service 
information referred to by the reference request 
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transmitted from the request transmission section . Further 
the server includes a service information transmission 
section transmitting to the service execution unit the 
service information corresponding to the reference request 
transmitted from the service execution unit. 

Further, according to the present invention, the 
service control network system includes a first domain, 
a first server accommodated in the first domain, a first 
service execution unit; and a terminal unit. The first 
server further includes; a storage section storing first 
service information, specifying a service to be provided 
to the terminal unit; and a service information 
transmission section transmitting the first service 
information stored in the storage section to the first 
service execution unit based on a reference request for 
the first service information, on receipt of the reference 
request from the first service execution unit. The first 
service execution unit includes; a first request 
transmission section transmitting a reference request for 
the first service information corresponding to a service 
initiation request or a registration request to the first 
server, on receipt of the service initiation request or 
the registration request from the terminal unit; and a first 
service provision section providing the service to the 
terminal unit based on the first service information 
referred to by the request transmitted from the first 
request transmission section. 



Still further, according to the present invention, 
the service control network system includes a first domain 
accommodating a first server and a terminal unit, and a 
second domain, to which the terminal unit moves, 
5 accommodating a second server and a second service 
execution unit. The first server includes; a storage 
section storing first service information specifying a 
service to be provided to the terminal unit; and a service 
information transmission section transmitting the first 

10 service information stored in the storage section to the 
second server based on a reference request for the first 
service information, on receipt of the reference request 
from the second server. The second service execution unit 
includes; a second request transmission section 

15 transmitting to the second server a reference request for 
the first service information corresponding to a service 
initiation request or a registration request, on receipt 
of the service initiation request or the registration 
request from the terminal unit; and a second service 

20 provision section ^providing the service to the -terminal- 
unit based on the first service information referred to 
by the request transmitted from the second request 
transmission section. The second server includes a transfer 
section transferring to the first server the reference 

25 request transmitted from the second request transmission 
section, and transferring to the second service execution 
unit the first service information transmitted from the 
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first server. 

Here, 'registration request' denotes a request for 
registration of the existence of a terminal unit with regard 
to a predetermined service. For example, this includes a 
5 request performed by a terminal unit to register the 
existence of the terminal unit itself against the SIP 
service in VoIP. 

According to the present invention, on receipt of a 
service initiation request or a registration request from 

10 the terminal unit, the service execution unit requests the 
server for service information (service control 
information) corresponding to the service initiation -r\ 
request or the registration request. This enables to 
identify the service the user desires to receive. Also, 

15 the service execution unit can acquire the service 
information corresponding to the identified service . Thus , 
it becomes possible for the service execution unit to 
perform a service control corresponding to each user and 
the service provided to the user. 
,-,20 — Further , according to the present invention) the > 
server is accommodated in a first domain formed in a 
communication network. The server includes; a storage 
section storing first service information specifying a 
service to be provided to a terminal unit accommodated in 

25 the first domain; a reception section receiving a reference 
request for the first service information transmitted from 
a first service execution unit accommodated in the first 
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domain for providing the service to the terminal unit; and 
a transmission section transmitting the first service 
information stored in the storage section to the first 
service execution unit, based on the reference request 
received by the reception section. 

Also, according to the present invention, the server 
accommodated in a first domain formed in a communication 
network includes; a storage section storing a first service 
information specifying a service to be provided to a 
terminal unit which is accommodated in the first domain 
and moved into a second domain .formed in the communication 
network; a reception section receiving a reference request 
for the first service information, which is transmitted 
from a second service execution unit accommodated in the 
second domain for providing the service to the terminal 
unit, and transferred by a second server accommodated in 
the second domain; and a transmission section transmitting 
the first service information stored in the storage section 
to the second service execution unit through the second 
server, based on the reference request received by the 
reception section. 

According to the present invention, the service 
execution unit is provided in a communication network for 
providing a service to a terminal unit accessing the 
communication network. The service execution unit 
includes; a storage section storing service information 
specifying the service; a transmission section 
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transmitting a reference request for the service 
information specifying the service corresponding to a 
service initiation request or a registration request to 
a server provided in the communication network for managing 
the service information, on receipt of the service 
initiation request or the register request from the 
terminal unit; a reception section receiving the service 
information transmitted from the server based on the 
reference - request transmitted from the transmission 
section / and storing the received service information into 
the storage section; and a service provision section 
providing the service to the terminal unit based on the 
service information stored in the storage section. 

Further scopes and features of the present invention 
will become more apparent by the following description of 
the embodiments with the accompanied drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a block diagram illustrating a 
conf iguration example of a service control network^system 
according to an embodiment of the present invention. 

FIG. 2A shows an example of a local SPC. 

FIG. 2B shows an example of a global SPC. 

FIG. 3 shows a flowchart illustrating the flow of L-SPC 
request message processing performed by an application 
authentication module. 

FIG. 4 shows a sequence diagram illustrating the 



processing flow from the transmission of a service 
initiation message by a user host terminal to the 
transmission of a G-SPC request message, and the reception 
of a G-SPC response message, by a service execution unit. 

FIG. 5 shows a flowchart illustrating the transmission 
processing flow of a G-SPC request message performed in 
an application authentication module. 

FIG. 6A shows a data structure of a G-SPC request message 
and an L-SPC request message. 

FIG. 6B shows a data structure of a G-SPC response 
message and an L-SPC response message. 

FIG. 7 shows a flowchart illustrating the reception 
processing flow of a G-SPC response message and an L-SPC 
response message performed in an application 
authentication module. 

FIG. 8 shows examples of a main SPC table, an L-SPC 
table and a G-SPC table respectively managed by an 
authentication server . 

FIG. 9 shows a block diagram illustrating a 
configuration example of a service control network system 
in operation example 1 . 

FIG. 10 shows a sequence diagram illustrating the 
processing flow of a service control network system in 
operation example 1. 

FIG. 11 shows a block diagram illustrating a 
configuration example of a service control network system 
in operation example 2. 
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FIG. 12 shows a sequence diagram illustrating the 
processing flow of a service control network system in 
operation example 2. 

FIG. 13 shows a block diagram illustrating a 
configuration example of a service control network system 
in operation example 3 . 

FIG. 14 shows a sequence diagram illustrating the 
processing flow of a service control network system in 
operation example 3. ~ 

FIG. 15 shows a block diagram illustrating a 
configuration example of a service control network system 
in operation example 4. 

FIG. 16 shows a sequence diagram illustrating the 
processing flow of a service control network system in 
operation example 4. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
The preferred embodiment of the present invention is 
described hereinafter referring to the charts and drawings . 
<Gonf igurat ion example of service control network system> 
FIG. 1 shows a block diagram of a configuration example 
of a service control network system in accordance with an 
embodiment of the present invention. By way of example, 
this service control network system is provided with three 
networks , which are access networks 1 , 2 , and a core network 
3. 

Access network 1 is , for example, a LAN, a wireless 
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LAN, or the like, which is accessed by a user host terminal 
HI (for example, a personal computer, a telephone set, or 
a personal computer with a telephone set) operated by the 
user. Also, access network 2 is, for example, a LAN, a 
wireless LAN, or the like, accessed by a user host terminal 
H2 (for example, a personal computer, a telephone set, or 
a personal computer with a telephone set). 

Core network 3 is, for example, the IPv6 Internet. 
According to the embodiment of the present invention, core 
network 3 is divided into, for example, three partial 
networks- (domains), which are referred to. as domain- Dl, 
domain D2, and relay domain D3 . 

In Domain Dl, an authentication server Al , an edge 
unit EN1, and a service execution unit SN1 are provided. 
In domain D2 , an authentication server A2 , an edge unit 
EN2 , and a service execution unit SN2 are provided. In relay 
domain D3 , a relay unit ( for example, a router ) R3 is provided . 
Additionally, by way of example, there are two domains Dl, 
D2 shown in FIG. 1. Also, one edge unit and one service 
execution unit are shown in- each domain v However y it may 
also be possible to include more than three domains in the 
network. Also, more than two edge units, and more than two 
service execution units as well, may be existent in each 
domain . 

Each authentication server Al , A2 is, for example, 
an AAA (Authentication, Authorization and Accounting) 
server, which performs authentication, authorization and 
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accounting functions . 

Authentication server Al is provided in domain Dl for 
which authentication server Al is responsible. At the time 
of access, authentication server Al authenticates a user 
host terminal ( for example, user host terminal Hi ) the home 
link of which is domain Dl. Authentication server Al also 
retains and manages a Service Profile Cache (SPC), which 
includes a service contract condition ( service information 
and service control information) to be referred to when 
a service execution unit (for example, service execution 
unit SN1 ) performs a service to the user host terminal of 
interest. On receipt of an SPC distribution request from 
the service execution unit, authentication server Al 
extracts an SPC maintained therein, and distributes the 
SPC to the service execution unit originating the request. 

Authentication server A2 also authenticates a user 
host terminal ( for example, user host terminal H2 ) the home 
link of which is domain D2 , for which authentication server 
A2 is responsible, and retains and manages the SPC for the 
user host terminal of interest. Upon request from the * 
service execution unit, authentication server A2 
distributes the SPC to the service execution unit 
originating the request. 

As will be described later, SPC is provided for each 
application (service) of each user. Each SPC is further 
divided into a Local SPC and a Global SPC , which are retained 
in authentication servers Al , A2 . Because the SPC is 
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provided for each application of each user, it becomes 
possible to provide the users with services customized on 
both an application-by-application basis and a 
user-by-user basis. 

Service execution units SN1 , SN2 are units executing 
a variety of services. Each service execution unit SN1, 
SN2 is a session control server (SIP server, where 'SIP' 
denotes session initiation protocol) providing an IP 
telephone function ( Voice-over-IP /or simply VoIP), any 
variety of Web servers, etc. in this embodiment, an 
application authentication module , which will be described 
later, is mounted on such a server providing the general 
services . 

Edge units EN1 , EN2 are network units located on the 
edges of each domain Dl, D2 . For example, edge units EN1 , 
EN2 are edge routers respectively located at the boundary 
between domain Dl and an external access network 1, and 
the boundary between domain D2 and an external access 
network 2. 

----- User host terminals Hi , H2 are terminal units each^ 
receiving a service based on a contract condition settled 
by each host. Domain Dl is a home link (home network) of 
user host terminal HI, and domain D2 is a home link (home 
network)of user host terminal H2 . Accordingly, 
authentication server Al retains and manages the SPC (Local 
SPC and Global SPC) for user host terminal Hi, and 
authentication server A2 retains and manages the SPC for 
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user host terminal H2 . 

Each user host terminal Hi , H2 may have a client function, 
etc. related to the service provided by each service 
execution unit SN1 , SN2 . For example, when VoIP is used, 
5 telephoning software controlling the SIP (Session 
Initiation Protocol) , etc. are installed in each user host 
terminal 

<Contents of .SPO 

As described earlier, each authentication server Al, 
10 A2 retains and.manages the SPC for each user host terminal 
(user) . The SPC is a data set in which service, behaviors 
required for controlling a service for use by each contract 
user (contract user host terminal) are described. By the 
use of this SPC , it becomes possible to provide an individual 
15 service for each user. The SPC is classified into a Local 
SPC (hereafter referred to as L-SPC) and a Global SPC 
(hereafter referred to as G-SPC ) , and managed accordingly. 
(1) Contents of L-SPC 

L-SPC is an SPC referred to by the service execution 
20- unit existent in the same domain as the domain accommodating »*v 
the contract user host terminal (home link of the contract 
user host terminal). For example, in FIG. 1, the L-SPC 
retained in authentication server Al accommodated in domain 
Dl is referred to by service execution unit SNl accommodated 
25 in the same domain Dl . 

Because the L-SPC is referred to within the same domain 
as the domain accommodating the host requesting for a 
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service, the L-SPC describes such conditions as commonly 
applicable to each service, which are not dependent on the 
service execution unit. For example, the L-SPC includes 
a port number, protocol information, etc. 

Also, the service described in the L-SPC is such a 
service that is identifiable to execute when a packet is 
originated from the user host terminal concerned. For 
example, the service corresponds to a service which is 
initiated based on a certain protocol type, not depending 
on a particular ASP (Application Service Provider ) . Namely, 
the service corresponds to a case of providing a common 
added value using a function of the present invention to 
a streaming broadcast service provided by a site. 

The L-SPC in the service execution unit is referred 
to as a decision condition for execution, together with 
the G-SPC in the opposite user host terminal. Namely, the 
L-SPC is referred to as an execution condition when an 
individual service according to the contract condition is 
provided to the user host terminal originating the service 
request- (packet ) . * — - . . : ... ;v -.„,- - * v.....,~ 

FIG. 2A is an example of the L-SPC. In this figure, 
item 1 denotes, in case of an information service by HTTP 
(Hypertext Transfer Protocol) without specifying a site, 
data to be transmitted from the service execution unit to 
the user host terminal is compressed. Also, item 2 denotes, 
in case of IP telephone (VoIP) without specifying a 
telephone operating company, a voice commercial message 
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(CM) is forwarded to the user host terminal before the start 
of communication, and the telephone charge of the user host 
terminal is discounted because of this CM insertion. 
(2) Contents of G-SPC 

G-SPC is an SPC referred to by a service execution 
unit existent in the domain which is different from the 
domain accommodating a contract user host terminal. For 
example, in FIG. 1, the G-SPC retained in authentication 
server Al accommodated in domain Dl is referred to by service 
execution unit SN2 . The contents of the G^SPC describe 
behavior of respective individual services.. : - 

A service type specified in the G-SPC describes control 
content for each site providing an application. As a typical 
example, in case of a streaming service, a particular 
service is specified in the G-SPC when the service for 
particular information (for example, for music program 
only) is to be specified. 

FIG. 2B shows an example of the G-SPC. As compared 
with FIG. 2A, it will easily be understood that the site 
is not specified in FIG. 2A, the site is specified in FIG.— 
2B, as a streaming site of a company A. For example, in 
item 1, when receiving a service from the streaming site 
company A, a commercial message is broadcasted for 30 
seconds before the start of the broadcast. With this, the 
user host terminal can receive the reduction of the service 
charge. 

distribution method of L-SPO 
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Next, a method for distributing the L-SPC from the 
authentication server to the service execution unit is 
described below. 

The L-SPC is an SPC related to a service executed in 
the service execution unit provided in the domain directly 
accommodating the user host terminal (home link of the user 
host terminal). The L-SPC must be distributed at the same 
time as the application execution. 

With regard to the L-SPC distribution method, the 
following two methods are applicable: a method, of 
distributing at the time of the service registration, prior 
to the service execution; and a method of sequentially 
distributing at the time of the service execution. These 
methods are described below in detail. 
(1) Distribution at the time of service registration 

In some IP services, service execution authorization 
is registered into the service execution unit when the 
location of a user host terminal into a particular domain 
(sub-network) is registered, or the access authentication 
is received, separately from registering each time the- 
service is initiated. For example, in the SIP for performing 
VoIP session control, a user host terminal registers its 
own existence into a neighboring SIP server by use of a 
'Register' message. 

This Register message is effective during the period 
as long as the user host terminal stays in the domain 
concerned. In the case that the contents of the L-SPC is 
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not changed frequently for a certain period, the service 
execution unit requests the authentication server 
authenticating the user host terminal concerned to transmit 
the L-SPC of the user host terminal originating the request, 
at the time of the registration prior to the use of the 
service. In reply to this request, the authentication 
server distributes the L-SPC to the service execution unit 
in a reply message. The distributed L-SPC is then stored 
in the service execution unit. 

The L-SPC distributed to and stored in the service 
execution unit is deleted when the , L-SPC becomes 
unnecessary because the user host terminal moves outside, 
or the like . The service execution unit manages the validity 
period necessary for the management of deletion, etc., 
using a management table for managing the validity period 
of the Register message related to the user host terminal . 
In such a way, providing a management mechanism proper to 
the L-SPC becomes unnecessary. 

Namely, the Register message registers to use the SIP 
performed by a service execution unit while -the user host* 
terminal is located near this service execution unit. On 
a certain condition such as the user host terminal having 
moved outside, the service execution unit determines the 
retention period is ended, and deletes the registered 
information. Meanwhile, because the L-SPC is used within 
the valid period of the Register message, such an action 
as deletion of a useless L-SPC can be operated in combination 



19 



with a management table of the Register message. This makes 
it unnecessary to provide a management mechanism proper 
to the L-SPC in the service execution unit. 

Thus , by performing the L-SPC management in the service 
execution unit in combination with the Register message 
management, a proper L-SPC management mechanism becomes 
unnecessary, which enables the load reduction of the 
service execution unit. 

The timing for triggering the service execution unit 
to request the authentication server for the L-SPC can be 
synchronized with ; the aforementioned registration 
operation into the service registration table . In the 
following description, by way of example, a case that the 
service execution unit is an SIP server is shown. A user 
host terminal transmits a first Register message to the 
SIP server located nearest to the user host terminal . When 
registering the user host terminal concerned into a user 
host terminal information table provided in the SIP server, 
the SIP server requests the authentication server for the 
L-SPC of the user host terminal concerned . The SIP server 
then receives the L-SPC from the authentication server, 
and stores the received L-SPC. 

(2) Successive distribution at the time of service 
execution 

The aforementioned distribution method performed at 
the time of service registration is applicable when the 
service execution unit has, as a service feature, a function 
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of user host terminal registration (authentication) prior 
to the use of the service. This method is suitable when 
modification of the SPC is infrequent. 

In contrast, there is another method for the L-SPC 
distribution applicable when a service has no registration 
procedure to the service execution unit (for example, SIP 
server and Web server) with regard to the service 
registration (such as a service to be executed each time 
on receipt of a request), in such a case, the L-SPC is 
distributed successively at the time of service execution. 

In this successive distribution, when the service 
execution unit receives a service request ( such as an HTTP 
request message) from a user host terminal, it is required 
for the service execution unit to identify that the received 
message is a first request message (a first within a certain 
past period) from the user host terminal originating the 
request . 

For this purpose, the service execution unit retains 
and manages a service use condition management table, and 
refers to this table; when the information related to the •■■> 
user host terminal originating the request message is not 
existent in this service use condition management table, 
the service execution unit recognizes that the message 
concerned is a first request message . The service execution 
unit then request the L-SPC to the authentication server 
located in the domain of the user host terminal originating 
the request. Thereafter, the service execution unit stores 
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the L-SPC, which is included in the response message 
transmitted from the authentication server, into the 
service use condition management table. 

Further, the service execution unit monitors the 
service use condition management table at certain intervals, 
and deletes user host terminal registration information 
the retention of which has elapsed for a certain time . Thus , 
it becomes possible to reduce a cost (in view of memory 
capacity, time required for management , etc.) for managing 
user host terminal, information which is not frequently 
used . 

distribution method of G-SPO 

The distribution of the SPC related to the service 
of the layer three (network layer, IP layer) , such as the 
QoS (Quality of Services) and the packet filtering, to the 
edge units may be operated in connection with the procedure 
of the access authentication or the location registration 
of the user host terminal. 

In contrast, a higher layer application (typically, 
-the layer seven) has a feature that the service execution- 
location differs content by content of the services. For 
example, service execution units (servers) providing the 
VoIP service or a variety of Web services are disposed in 
the network with the optimal locations and numbers. 
Accordingly, the locations to which the SPC is distributed 
depend on the service execution units providing the 
service . 
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Therefore, with regard to the high-layer services, 
in order to distribute the SPC according to an individual 
condition on a per contract user host terminal basis, it 
is necessary to consider an SPC distribution method 
5 suitable for individual service execution units locating 
scattered in the network. 

According to the embodiment of the present invention, 
the G-SPC is distributed to the service execution units 
in the following way: When a user host terminal having 
10 contracted the service transmits, a service initiation 
request message to a service execution unit, the service 
execution unit requests the authentication server managing 
both the contract and the authentication information of 
the user host terminal concerned to send the G-SPC of the 
15 user host terminal. The authentication server replies to 
this request by transmitting a response message including 
the G-SPC of the user host terminal concerned. 

Here, when the domain of the service execution unit 
is different from the domain of the user host terminal 
20 originating the request, the service execution- unit 
requests for the G-SPC an authentication server located 
in the domain of the user host terminal originating the 
request, through another authentication server (a local 
authentication server) located in the domain of the service 
25 execution unit. 

A sequence of actions through the above-mentioned 
procedure is referred to as 'application authentication' 
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in this embodiment of the present invention, by which the 
service execution unit obtains the G-SPC of the user host 
terminal and determines whether the service is to be 
executed, and which of the service content is to be executed. 
5 As for the services provided under the identical 

condition, irrespective of a subscriber's contract 
condition, such an individual service control is not 
required. The aforementioned application authentication 
may be applicable when there exists a condition on a contract 

10 user by user basis in addition to the common condition. 
Application authentication function> 

A variety of service execution units existent in the 
network employ different execution start timings, and 
different protocols . Therefore, in order to provide service 

15 control according to the embodiment of the present 
invention, it is necessary to provide a common means so 
that each service execution unit obtains the L-SPC or the 
G-SPC of the user host terminal requesting for the service 
execution. 

20 - . as such a common means r an application authentication 
module (which is exemplarily comprised of software) is 
added to the service execution unit according to the 
embodiment of the present invention (such as SIP server 
and Web server). The application authentication denotes 

25 an acquisition of the G-SPC and a decision operation of 
service execution content based on the description of the 
acquired G-SPC. 
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The application authentication module has an extended 
AAA client function and a G-SPC management function. Here, 
the 'extended AAA client function' is provided on the 
service execution unit side, enabling interactions between 
the application authentication function and an 
authentication server (AAA server) so as to obtain the G-SPC 
of a user host terminal for service control from the 
authentication server accommodating the user host terminal 
concerned. Also, the 'G-SPC management function' is 
provided for retaining the G-SPC of each user host terminal 
for a certain period. 

When executing the service, the service execution unit 
works according to the G-SPC content. 

Hereafter, there will be described an L-SPC reguest 
message transmission processing, a G-SPC reguest message 
transmission processing, and an L-SPC/G-SPC response 
message reception processing performed by the application 
authentication module. 

FIG. 3 shows a flowchart illustrating the L-SPC reguest 
-message •transmission processing by the application 
authentication module. 

The application authentication module is in a message 
reception waiting condition (S21 ) . On receipt of a message 
(Y in S21), the application authentication module checks 
the port number of TCP (Transmission Control Protocol) or 
UDP (User Datagram Protocol) in the message (S22). If this 
port number is the port number the service execution unit 
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is monitoring, the application authentication module 
executes the following processing, triggered by this 
message reception. 

First, based on a service initiation message from the 
user host terminal, the application authentication module 
decides whether the user host terminal is located in the 
same domain as the service execution unit concerned (S23) . 
This decision is made by comparing the source address (IP 
address) of the message with the address (IP address) of 
the service execution unit . 

When the service initiation message is originated in 
a user host terminal in the same domain (Y in S23), the 
application authentication module extracts, from the 
service initiation message, user host terminal information 
originating the service initiation request (S24 ) . This user 
host terminal information is at least one of the IP address 
of the user host terminal (the transmission source address 
of the service initiation message) and the NAI (Network 
Access Identifier) of the user host terminal. 

On the other hand / when the service initiation message 
is originated in a user host terminal not in the same domain, 
the L-SPC is not necessary, and therefore the application 
authentication module returns to the message reception 
waiting condition. 

Next to the step S24, the application authentication 
module decides whether the user host terminal can be 
uniquely identified, based on the extracted user host 



26 



terminal information (S25) . For example, when the service 
initiation message is transmitted through a proxy server, 
the address of the user host terminal originating the 
service request is hidden by the proxy server. In such a 
case, the request source address becomes the address of 
the proxy server, and therefore, it is not possible to 
identify the user host terminal uniquely. 

As such, when the user host terminal cannot be 
identified uniquely (N in S25), the application 
authentication module sets a predetermined default .L-SPC 
(specified value) into an.L-SPC request parameter (S27). 
On the contrary, when the user host terminal can be 
identified uniquely (Y in S25), the application 
authentication module sets information which can uniquely 
identify the user host terminal into the L-SPC request 
parameter (S26). 

Thereafter, the application authentication module 
generates an L-SPC request message (S28), and transmits 
the generated L-SPC request message to the authentication 
server in the same domain (S29). , ...,„,„ , 

After transmitting the L-SPC request message, the 
application authentication module returns to the message 
waiting condition (S21). 

FIG. 6A shows the data structure of the L-SPC request 
message (or the G-SPC request message). The L-SPC request 
message (or the G-SPC request message) includes an 
IP/TCP/UDP packet header, a message type code, host 
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identification information 1 for service control (for 
example, the IP address of a user host terminal) and host 
identification information 2 for service control (for 
example, the NAI of the user host terminal). 

The IP/TCP/UDP packet header includes a port number, 
by which a particular service (application) is identified. 
With regard to the SPC of the host terminal (user) identified 
by either host identification information 1 or host 
identification information 2, an L-SPC (or G^SPC) related 
to the service identified by the port number is searched 
and extracted by the authentication server. Thus,: the 
service execution unit can obtain the SPC on a user-by-user 
basis, as well as on an application-by-application basis . 

The message type code denotes whether the message of 
interest is an L-SPC request message or a G-SPC request 
message. Based on this message type code, the unit on the 
reception side (here, the authentication server) 
identifies the message and recognizes whether the L-SPC 
is to be searched and extracted, or the GrSPC is to be 
searched and extracted. Host identification information 
1 or 2 is the information to be set as an L-SPC request 
parameter in either step S26 or S27. 

FIG. 4 shows a sequence diagram illustrating the 
processing flow from the transmission of a service 
initiation message by a user terminal to the transmission 
of a G-SPC request message and the reception of a G-SPC 
response message by a service execution unit. This diagram 



28 



illustrates a sequence diagram exemplifying a service 
control network system shown in FIG. 1. 

First, the user operates user host terminal HI and 
requests service execution unit SN2 for service, and 
thereby user host terminal HI transmits a service 
initiation message for the service concerned to service 
execution unit SN2 (SI). This service initiation message 
is, for example, a message accessing the home page of service 
execution unit SN2 (Web server). 

Here, it may also be possible that this service 
initiation message is received in service execution unit. 
SN1, and service execution unit SN1 decides the necessity 
of the L-SPC related to user host terminal HI. And, as a 
result of this decision, when L-SPC is decided necessary, 
service execution unit SN1 may request authentication 
server Al for the L-SPC and receive the L-SPC therefrom. 

On receipt of the service initiation message, service 
execution unit SN2 decides whether the reference to G-SPC 
is necessary with regard to the decision whether the service 
denoted in the service initiation message is necessary ( S2 ) . 
This decision is made based on whether an effective G-SPC 
(i.e. G-SPC before expiration of the effective period) is 
stored in service execution unit SN2 , and whether it is 
necessary for service execution unit SN2 to refer to the 
G-SPC in the user host terminal originating the request 
at the time of performing the service concerned. 

When service execution unit SN2 decides that referring 
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to the G-SPC is necessary (Y in S2), the service execution 
unit SN2 generates a G-SPC request message for requesting 
authentication server A2 for the G-SPC of user host terminal 
HI requesting the service execution, and transmission the 
request to authentication server A2 in domain D2 (S3) . The 
G-SPC request message has the data structure previously 
shown in FIG. 6A. 

Authentication server A2 recognizes that user host 
terminal Hi is accommodated in (and managed by) 
authentication server Al (namely, domain Dl) from the 
.contents of the G-SPC request message (namely, the IP 
address or the NAT of user host terminal HI. Refer to FIG. 
6A. ) , and transfers the received G-SPC request message to 
authentication server Al . Here, both authentication 
servers have a relation of mutual trust, and each 
authentication server has the IP address of the other 
authentication server in advance. The G-SPC request message 
is transferred based on this IP address of the opposite 
server. 

On receipt - of the G-SPC request ^ messagey 
authentication server Al searches for the G-SPC of the user 
host terminal Hi (S4). If there exists the G-SPC of user 
host terminal HI, authentication server Al generates a 
G-SPC response message which includes the searched G-SPC, 
and transmits the response message to service execution 
unit SN2 originating the request (S5). 

FIG. 6B shows the data structure of the G-SPC response 
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message (or the L-SPC response message) . The G-SPC response 
message (or the L-SPC response message) includes an 
IP/TCP/UDP packet header, a message type code, host 
identification information 1 (for example, the IP address 
of user host terminal HI), and host identification 
information 2 (for example, the NAI of user host terminal 
HI), a searched SPC, and a return code. 

The 'message type code' denotes whether the message 
of interest is a G-SPC response message or an L-SPC response 
message. Based on this message type code, the unit on the 
reception side ( service execution unit SN2 ) identif ies the 
message. The 'searched SPC ' is the G-SPC (or the L-SPC) 
searched and found by the authentication server. The 
'return code' is information related to the message 
processing result, etc., which has, for example, a value 
'0' indicative of the search successfully completed, '2' 
indicative of an SPC corresponding to the request for search 
not found, and '3' indicative of the SPC included in the 
message being a default SPC. 

Referring back to FIG . 4 , this G-SPC response message 
is transmitted to authentication server A2 , and thereafter 
transferred from authentication server A2 to service 
execution unit SN2 . 

On receipt of the G-SPC response message, service 
execution unit SN2 checks the normality of the G-SPC 
response message (S6) . This normality of the G-SPC response 
message is checked by whether the G-SPC response message 
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includes a G-SPC. When the G-SPC is included, the G-SPC 
response message is decided normal. 

When the G-SPC response message is decided normal, 
service execution unit SN2 extracts the G-SPC included in 
5 the G-SPC response message, and stores the G-SPC into an 
SPC management table (S7). 

FIG. 5 shows a flowchart illustrating a transmission 
processing flow of the G-SPC request message performed by 
-the application authentication module. There is shown a 
10 detailed transmission processing s the details of step S3 
shown in FIG. 4) of the G-SPC request message performed 
in service execution unit SN2 (application authentication 
module) . 

The application authentication module stays in a 
15. message reception waiting condition (S31). On receipt of 
a message (YinS31), the application authentication module 
checks the TCP/UDP port number of the received message ( S32 ) . 
If the port number is a port number to which the service 
execution unit is monitoring, triggered by this message 
20 reception, -the following processing: -is performed. *• 
First, the application authentication module decides 
whether the application to which the initiation is 
requested by the service initiation message from the user 
host terminal is supported (S33). This decision is 
25 performed based on the port number, etc. included in the 
service initiation message. 

If the application is supported by the service 
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execution unit ( Y in S33 ) , the application authentication 
module extracts, from the service initiation message, the 
user host terminal information originating the request for 
service initiation (S34). This user host terminal 
5 information is at least one of the IP address of the user 
host terminal (the transmission source address of the 
service initiation message) and the NAI (Network Access 
Identifier) of the user host terminal. 

On the other hand, if the service execution unit does 
10 not support the application, the G-SPC is not necessary, 
-■ and therefore the application authentication module 
returns to .the message reception waiting condition. : 

Next to the step S34, the application authentication 
module decides whether the user host terminal can be 
15 identified uniquely, based on the extracted user host 
terminal information (S35). For example, when the service 
initiation message is transferred through a proxy server, 
the user host terminal address originating the service 
request is hidden by the proxy server, in such a case, the 
20 < request source address-becomes the address of the proxy- 
server, and therefore, it is not possible to identify the 
user host terminal uniquely. 

When the user host terminal uniquely cannot be 
identified uniquely ( N in S35), the application 
25 authentication module sets a predetermined default G-SPC 
(specified value, as described later) into a G-SPC request 
parameter (S37). On the contrary, when the user host 
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terminal can be identified uniquely (Y in S35), the 
application authentication module sets information which 
can uniquely identify the user host terminal into the G-SPC 
request parameter (S36). 
5 Following this , the application authentication module 

generates a G-SPC request message (S38) , and transmits the 
generated G-SPC request message to the authentication 
server in the same domain (S39). Thereafter, the 
application authentication module returns to the message 
10 waiting condition. 

Now, hereafter, a reception processing of the G-SPC 
response message and the L-SPC response message performed 
by the application authentication module (service 
execution unit) is described. FIG. 7 shows a flowchart 
15 illustrating the reception processing of the G-SPC response 
message and the L-SPC response message in the application 
authentication module. 

The application authentication module is in the 
message waiting condition (S41). Each time a message is 
20 -received (Y in S41) , the application authentication module- 
monitors the message type code of the received message ( S42 ) . 
The message type code is decided based on the message type 
code shown in FIG. 6B. 

When the application authentication module decides 
25 that the reception message is an SPC response message (the 
L-SPC response message or the G-SPC response message) based 
on the message type code (Y in S43), the application 
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authentication module checks the normality of the message 
based on the return code (refer to FIG. 6B) (S44 ) . Meanwhile, 
when the reception message is not an SPC response message, 
the application authentication module returns to the 
5 message waiting condition again (S41). 

In the step S43, when the message is decided normal, 
the application authentication module decides whether the 
message includes an SPC (L-SPC or G-SPC) (S45). 

When the SPC is included (Y in S45), the application 
10 authentication module extracts the SPC, and registers the 
extracted SPC into the SPC management table (S46 ) . Namely, 
the application authentication module registers the G^SPC 
in a G-SPC management table, and registers the L-SPC in 
an L-SPC management table (S49, S50). In other cases, the 
application authentication module performs a message error 
processing (S51). Thereafter, the application 
authentication module returns to the message reception 
waiting condition (S41). 

In the step S45, when the SPC is not included, the 
application authentication module sets the default G-SPC- 
in the G-SPC request parameter (S48), and thereafter 
returns to the reception message waiting condition ( S4 1 ) . 

In the step S44, when the message is decided abnormal, 
the application authentication module performs a message 
error processing (S47), and returns to the reception 
message waiting condition (S41). 

<G-SPC and L-SPC management function in authentication 
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server> 

As having been described earlier, the authentication 
server (AAA server) retains the individual SPC (L-SPC and 
G-SPC) of each contract user (user host terminal). 
5 in order to manage the individual SPC of each user, 

according to the embodiment of the present invention, the 
authentication server is provided with a main SPC table 
specifying the L-SPC and G-SPC of each user, an L-SPC table 
for each user specifying the L-SPC on a user-by-user basis , 
10. and a G-SPC table for each user specifying the G-SPC also 
on a user-by-user basis.,: , 

As shown in FIG. 8, the main SPC table includes a user 
number for identifying each contract user and basic 
contract information, as the basic information of each user. 
15 Also, the main SPC table includes an L-SPC pointer 
indicative of the pointer to the L-SPC table foe each user, 
and a G-SPC pointer indicative of the pointer to the G-SPC 
table for each user. 

The L-SPC table provided for each user is a table for 
20 managing the L-SPC on a user-by-use r-b as is . in FIG < 8> the 
L-SPC for a user having the user number 000001 is shown. 
The L-SPC table for each user includes SPC number, condition 
1 and condition 2 for applying the L-SPC, and SPC content. 
The G-SPC table for each user is a table for managing 
25 the G-SPC on a user-by-user basis. In FIG. 8, the G-SPC 
for the user having the user number 000001 is shown. The 
G-SPC table for each user includes SPC number, condition 
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1 and condition 2 for applying the G-SPC, and SPC content. 

By managing the SPC using such tables, the 
authentication server can set and retain a plurality of 
information sets (search keys) for identifying hosts, on 
5 an assumable application-by-application basis , separately 
for the G-SPC and the L-SPC. 

Here, in the service execution unit, there may be a 
case that the inherent information of the user host terminal 
originating the request cannot be acquired because the 
LO service execution request originated from the user host 
terminal is intercepted by an HTTP proxy Lserver, etc . For 
example, as for an HTTP request transmitted through the 
HTTP proxy server, the request source information 
(transmission source address, etc.) is replaced by the 
5 information related to the proxy server. Therefore, the 
address of the user host terminal originating the request 
cannot be identified. 

In such a case, the application authentication 
function in the service execution unit transmits an SPC 
) request message- to the nearest authentication server in. 
a state of 'detailed request source information not 
available'. On receipt of this message, the nearest 
authentication server estimates the location of the user 
host terminal originating the request from the proxy server 
indicative of the request source information, and returns 
a G-SPC of a general condition in which a particular user 
is not identified. Such an SPC is referred to as default 
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SPC. 

<Operation example> 

Next, typical operation examples of the service 
control network system are described exemplifying the 
5 telephone communication using VoIP. 
(1) Operation example 1 

Operation example 1 denotes an example of the execution 
procedure of the SPC distribution and the individual 
service control triggered by the application 

10 authentication f when user host terminals of the service 
contract users (both the calling party and the called party 
of a telephone call) are located in an identical home link, 
and the service execution unit is existent in the same link 
as the user host terminals. 

15 FIG. 9 shows a block diagram illustrating a 

configuration example of the service control network system 
in this case. FIG. 10 shows a sequence diagram illustrating 
a processing flow of the service control network system 
in this case. 

20 In FIG. 9, user- host terminal HI of the calling party 

provided in a subscriber's residence, etc. is located in 
a home link (domain Dl ) . User host terminal H3 of the called 
party provided in a call center is also located in the 
identical domain Dl. Further f service execution unit SN1 

25 is existent in the identical domain Dl, and acquires the 
L-SPC (L-SPC (A)) of user host terminal HI and the L-SPC 
(L-SPC (C)) of user host terminal H3 from authentication 
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server Al in the domain 01 . Additional , user host terminal 
HI and user host terminal H3 are accomodated in an access 
network. 

The user (service contract user, of user host terminal 
5 HI uses the IP telephone function (for example, VoIP 
software, provided in user host terminal HI, and operates 
the terminal to ordinate a call by designating the opposite 
party (here, user host terminal H3,(S61 i„ fig. 10) . 

initiated by the user's dial operation, user host 
10 terminal HI generates a service initiationmessage (session 

initiation messaae /ctd tt\*ti + * — 

sage (SIP-lnvite message ,, designating the 

opposite user host terminal tt~~ ^ 

st terminal H3 . user host terminal HI then 

transmits the generated service initiation message to the 
nearest service execution unit (SIP server , SHI through 
15 edge unit EN1 , solid line with arrow (1, in FIG. 9,. Because 
user host terminal HI recogni.es the location , IP address , 
or the lixe, of service execution unit SN1 i„ advance, user 
host terminal HI can transmit the service initiation 
message to service execution unit SN1 . 
20-,. Service-execution unit SN1 detects the initiation of • . 
the service by receiving the SIP- Invi te message from user 
host terminal HI . Service execution unit SN1 then decides 
whether it is necessary to request for the l-spc (a, of 
user host terminal HI (a request to authentication server 
» Al ) at the time of the service execution , that is , generation 
of a VoIP session, (sym bol (2) in fig. 9, and S62 in fig. 
10, . 
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As described earlier, when L-SPC (A) is acquired in 
advanceby the Register message, or when the L-SPC (A) having 
been acquired by the L-SPC request message last time the 
service is executed is still effective and is not deleted, 
it is decided that the request for the L-SPC (A) is not 
necessary. Meanwhile, when the L-SPC (A) is not acquired 
yet or when the L-SPC (A) once acquired has been deleted 
because of expiration of the effective period, it is decided 
that the request for the L-SPC (A) is necessary. In the 
following description, it is assumed the request for the 

L-SPC (A) is decided necessary „ 4 , 

With this decision, service execution unit SNl 
generates the L-SPC request message, and transmits the 
generated L-SPC request message to authentication server 
Al which manages user host terminal HI (S63 in FIG. 10). 
Here, this L-SPC request message is transmitted, for 
example, by use of Diameter, which is a host authentication 
protocol . 

On receipt of the L-SPC request message related to 
user host terminal Hi from service execution unit •-■ SNl v 1 
authentication server Al searches the database for the 
L-SPC (A), and extracts the L-SPC (A) therefrom (S64 in 
FIG. 10). 

Authentication server Al transmits the extracted L-SPC 
(A) back to service execution unit SNl having originated 
the request by use of an L-SPC response message ( for example, 
a Diameter authentication response message) (S65). 
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Here, when the L-SPC (A) has already been in service 
execution unit SN1, the processing steps S63 to S65 is 
omitted. 

Service execution unit SN1 then extracts the L-SPC 
5 (A) included in the L-SPC response message received from 
authentication server Al , and stores the extracted L-SPC 
(A) into the management table owned by the service execution 
w unit SN1 (S66 in PIG. 10), and initializes the service 
- execution function according to the L-SPC description 
10 content (symbol ( 3 ) in PIG.. 9,: and S67 in FIG. 10). 

Triggered by the setting of L-SPC (A), service 
execution unit SN1 transfers the service initiation message 
(SIP-invite message) to the destination user host terminal 
H3 (solid line with arrow (4) in FIG. 9). 
15 After transmitting the SIP-invite message to user host 

terminal H3 , service execution unit SN1 waits for a response 
from user host terminal H3 (off-hook operation of the 
telephone terminal). 

If it is not possible for user host terminal H3 to 
20 receive the call because of user host terminal H3 being 
busy or any other reason, service execution unit SN1 
executes a service specified by L-SPC (A) for a period of 
keeping user host terminal HI waiting (for example, a 
service of a voice CM cast for 15 seconds, information 
25 service of a waiting time still needed, or the number of 
people in waiting, etc.), using another communication 
protocol (broken line with arrow (4) in FIG. 9). 
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When the user (service contract user) of user host 
terminal H3 operates the terminal to respond to the 
connection request from user host terminal HI, user host 
terminal H3 transmits a service response message (SIP-Ack 
5 (acknowledgement) message), triggered by this operation 
(S68 in FIG. 10 ) . 

The SIP-Ack message transmitted from user host 
terminal H3 is forwarded to user host terminal HI through 
service execution unit SNl. 

10 When user host terminal HI receives the SIP-Ack message . 

from user host terminal H3 , the session between. user host 
terminal HI and user host terminal H3 is established. 
Thereafter, voice packets are interchanged 
bi-directionally between these user host terminals, thus 

15 the users of the two user host terminals become able to 
communicate. 

Additionally, the L-SPC (C) shown in FIG. 9 is the 
L-SPC of user host terminal H3 , which is transmitted from 
authentication server Al to service execution unit SNl when 
20- - necessary. . .. 

(2) Operation example 2 

Operation example 2 denotes an example of the execution 
procedure of the SPC distribution and the individual 
service control triggered by the application 
25 authentication, when user host terminals of the service 
contract users are located in an identical home link, and 
the service execution unit is existent outside the home 



42 



link of the user host terminals. 

FIG. 11 shows a block diagram illustrating a 
configuration example of the service control network system 
in this case. FIG. 12 shows a sequence diagram illustrating 
a processing flow of the service control network system 
in this case. 

The difference of FIG. 11 from FIG. 9 is that, in FIG. 
11, user host terminal H2 of a call center is accommodated 
in domain D2, which is located* outside of domain Dl (home 
link) of user host terminal HI , and accordingly the service 
is executed by service execution unit SN2 in domain D2. 
In such a case, service execution unit SN2 requests 
authentication server Al for the G-SPC of user host terminal 
HI (which is referred to as G-SPC (A)) necessary for the 
service execution. 

Additionally, in FIG. 11, service execution unit SN1 
and service execution unit SN2 are provided in the core 
network, and a relay unit TS relaying the control protocol 
from these service execution units is provided in a relay 
domain. This is based on a case of -•■•the - VoIP voice 
communication network having a hierarchical structure 
similar to the conventional telephone switching system. 

The user (service contract user) of user host terminal 
HI uses the IP telephone function (for example, VoIP 
software) of user host terminal HI, and performs a call 
origination operation designating the opposite party (user 
host terminal H2) (S71 in FIG. 12). 
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With this user's dial operation, user host terminal 
HI generates a service initiation message (session 
initiation message, SIP-invite message) in which the 
opposite user host terminal H2 is specified, and transmits 
5 this message to the nearest service execution unit SN1 (SIP 
server) (arrow (1) in FIG. 1 1 ). User host terminal HI knows 
the location (IP address, or the like) of service execution 
unit SNlin advance, and therefore user host terminal HI 
can transmit the session initiation message- to service 
10 execution unit SN1 . 

Receiving the :SIP-Invite message from user host 
terminal HI , service execution unit SN1 detects the service 
initiation, when executing the service (generation of the 
VoIP session) , service execution unit SN1 decides whether 
15 it is necessary to refer to the L-SPC (A) of the calling 
party, i.e. user host terminal HI (S72 in FIG. 12). This 
decision criterion is a control rule the service execution 
unit owns individually. 

Here, it is assumed that the L-SPC (A) has already 
20 been acquired by use of a Register message, and - t hat-no - 
reference is required, with this decision, service 
execution unit SN1 does not execute the processing with 
regard to the acquisition of the L-SPC (A). 

Using the ordinary SIP message processing function, 
25 service execution unit SN1 transmits the SIP-invitemessage 
to service execution unit (SIP server) SN2 , which 
accommodates the called user host terminal H2, through 
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relay unit TS (arrow (1) in FIG. 11). 

On receipt of the SIP-invite message from service 
execution unit SN1, service execution unit SN2 recognizes 
this message as an SIP-invite message received from the 
5 external domain Dl . After this , when initiating the service 
concerned, service execution unit SN2 checks whether it 
is necessary to refer to the individual service condition 
of user host terminal HI, namely, the G-SPC of user host 
terminal HI (G-SPC (A)) (symbol (2) in FIG. 11, and S73 
10 in FIG. 12). Here, in the following description, it is 
assumed that reference to the G-SPC . (A) is . decided- 
necessary. 

Based on this decision, service execution unit SN2 
generates a G-SPC request message (Diameter message) with 

5 regard to user host terminal HI. Service execution unit 
SN2 then transmits the generated G-SPC request message to 
authentication server Al in the home link (domain Dl) of 
the calling user host terminal HI through authentication 
server A2 located in the domain D2 of the service execution 

) unit SN2 (broken line: with arrow ( 3 ) - in FIG. 11, -and S74 
in FIG. 12 ) . 

On receipt of the G-SPC request message from service 
execution unit SN2 , authentication server Al searches the 
database and extracts the G-SPC (A) therefrom (S75 in FIG. 
12). 

Next, authentication server Al transmits the extracted 
G-SPC (A) back to the service execution unit SN2 originating 
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the request by use of a G-SPC response message (Diameter 
authentication response message) (broken line with arrow 
(4) in FIG. 11, and S76 in FIG. 12). 

Service execution unit SN2 extracts the G-SPC (A) from 
5 the G-SPC response message, and stores the G-SPC (A) into 
the management table owned by service execution unit SN2 
(S77 in FIG. 12). Next, service execution unit SN2 
initializes the service execution function according to 
the description content in G-SPC (A) (symbol (5) in FIG. 
10 11, and S78 in FIG. 12). 

-Triggered by the G-SPC (A) set in service execution 
unit SN2, service execution unit SN2 transmits an 
Sip-invite message to the called user host terminal H2 , 
and then waits for a response from user host terminal H2 
15 (an off-hook operation of the telephone terminal) . During 
waiting for the response, user host terminal HI receives 
from service execution unit SN2 a service (broadcast of 
a CM, information on the waiting time, etc.) according to 
the G-SPC (A) (broken line with arrow (6) in FIG. 11). 
20 - By operating the- terminals the user of user- host 
terminal H2 responds to user host terminal HI against the 
connection request from user host terminal HI. By this 
operation, user host terminal H2 transmits a service 
response message (SIP-Ack (acknowledgement) message) (S79 
:5 in FIG. 12 ) . The SIP-Ack message transmitted from user host 
terminal H2 is forwarded to user host terminal HI through 
service execution unit SN2, relay unit TS , and service 
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execution unit SN1 . 

When user host terminal HI receives the SIP-Ack message 
transmitted from user host terminal H2 , the session between 
user host terminal HI and user host terminal H2 is 
established. Thereafter, voice packets are interchanged 
bi-directionally between the two user host terminals, and 
the communication proceeds. 

Additionally, the L-SPC (C) shown in FIG. 11 is the 
L-SPC of user host terminal H2, which is transmitted from - 
authentication server A2 to service execution unit SN2 when 
necessary. 

(3) Operation example 3 

Operation example 3 denotes an example of the execution 
procedure of the SPC distribution and the individual 
service control triggered by the application 
authentication, when a user host terminal of the service 
contract user moved out of the home link into another link 
(domain), and a service execution unit is existent in the 
local link. 

FIG. 13 shows a block- diagram illustrating • a 
configuration example of the service control network system 
in this case. FIG. 14 shows a sequence diagram illustrating 
a processing flow of the service control network system 
in this case. 

In FIG. 13 , there is shown a case that the user ( service 
contract user) of user host terminal HI who was 
communicating with a fixed line at the subscriber's 
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residence moves to a temporary access network ( for example, 
a wireless LAN hot spot) provided by the same network 
operating agency, and initiating a call from this point 
to user host terminal H3 provided in a call center. The 
5 user of user host terminal HI uses a user host terminal 
HI' (for example, a portable telephone) at the location 
the user moves to. However, both of the user host terminals 
(i.e. user host terminal HI and user host terminal HI') 
are used by the same service contractor , and therefore the 
service provided for both user host terminals HI, HI ' is 
specified by the same L-SPC (L-SPC (A.)) or the same G-SPC 
(G-SPC (A) ) . Also, the temporary access network, user host 
terminal HI', and user host terminal H3 are accommodated 
in a domain D3 . Domain D3 includes an authentication server 
A3 and a service execution unit SN3 . 

First, the user (service contract user) of user host 
terminal HI' operates the IP telephone function of the 
terminal to originate a call by designating the opposite 
party for communication (i.e. user host terminal H3 ) . 

initiated- by the user's dial operation; -user -host 
terminal HI' generates a service initiation message 
(SIP-lnvite message) designating user host terminal H3 on 
the opposite party, and transmits the generated service 
initiation message to the nearest service execution unit 
(SIP server) SN3 (arrow (1) in FIG. 13, and S81 in FIG. 
14 ) . User host terminal HI ' recognizes the location of the 
nearest SIP server in advance, and thereby the service 
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initiationmessage is transmitted to service execution unit 
SN3 . 

The SIP-invite message transmitted from user host 
terminal HI' is received in service execution unit SN3 . 
5 When executing the service concerned (generation of a VoIP 
session), service execution unit SN3 decides it is 
necessary to refer to the L-SPC (A) of user host terminal 
HI' on the calling party (S82 in FIG. 14). The reason.for 
the necessity of the L-SPC (A) is because, in the initial 
10 condition, the L-SPC (A) is not existent in the service 
execution unit SN3 located in domain D3 to which user . host 
terminal Hi' of interest has moved. 

Here, user host terminal HI ' is accommodated in domain 
D3, which is different from domain Dl. However, because 
L5 service execution unit SN3 provides the service in the same 
domain D3, the L-SPC (A) is referred to, instead of the 
G-SPC (A). 

As a result of this decision, service execution unit 
SN3 transmits an L-SPC request message related to the L-SPC 
0 < A > of user hos t terminal HI ' (HI ) to authentication server 
A3 in domain D3 (broken line with arrow (3) in FIG. 13). 

On receipt of the L-SPC request message from service 
execution unit SN3 , authentication server A3 detects from 
the message content that user host terminal HI' (HI) is 
accommodated in authentication server Al, and transfers 
the received L-SPC request message to authentication server 
Al located in domain Dl (broken line with arrow ( 3 ) in FIG. 
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13 ) . 

Authentication server Al then receives the L-SPC 
request message, extracts the L-SPC (A) related to user 
host terminal HI from the database, and transmits the 
5 extracted L-SPC (A) back to service execution unit SN3 
having originated the request by use of an L-SPC response 
message. The L-SPC response message is transmitted to 
service execution unit SN3 through authentication server 
A3 (broken line with arrow (4) in FIG. 13). 
0 ; Service execution unit SN3 extracts the L-SPC related 

.» to user host terminal HI out of the L-SPC response message 
received from authentication server A3, and stores the 
extracted L^SPC into the SPC management table owned by 
service execution unit SN3 . Further, service execution unit 
io SN3 initializes the service execution function according 
to the description content in the acquired L-SPC (S86 in 
FIG. 14). 

Triggered by the L-SPC (A) set in service execution 
unit SN3, service execution unit SN3 transfers the 
SlP-invite message to the destined user host terminal H3 -. 

Service execution unit SN3 then waits for a response 
from user host terminal H3 (an off -hook operation of the 
telephone terminal ) . During this period, service execution 
unit SN3 provides a service according to the L-SPC (A) 
content to user host terminal HI' (broken line with arrow 
(5)). For example, an advertisement, or the like, is 
provided to user host terminal HI ' by means of an appropriate 
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message . 

By operating the terminal unit, the user of user host 
terminal H3 responds to the connection request transmitted 
from user host terminal HI ' . As a result of this operation, 
user host terminal H3 transmits an SlP-Ack 
(acknowledgement) message, as a response to user host 
terminal HI ' . 

The SIP-Ack message transmitted by user host terminal 
H3 is forwarded to user host terminal HI' through service 
execution unit SN3 . 

When user host terminal HI ' receives the SIP-Ack 
message from user host terminal H3, the session between 
user host terminal HI ' and user host terminal H3 is 
established. Thereafter, voice packets are interchanged 
bi-directionally between user host terminals HI', H3 . 

Additionally, in FIG. 13, an L-SPC (D) is the L-SPC 
of the user host terminal H3 . 
(4) Operation example 4 

Operation example 4 denotes an example of the execution 
procedure of the ' SPC -distribution- and the individual 
service control triggered by the application 
authentication, when a user host terminal of the service 
contract user moved out of the home link into another link 
and stays there, and a user host terminal of another service 
contract user on the opposite party and a service execution 
unit are located in an external link. 

FIG. 15 shows a block diagram illustrating a 
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configuration example of the service control network system 
in this case. FIG. 16 shows a sequence diagram illustrating 
a processing flow of the service control network system 
in this case. 

5 In FIG. 15, during the situation that the service 

contract user of user host terminal HI moved out of the 
home link (domain Dl) and stays in another link (domain 
D4 ) , communication is performed with the opposite user host 
terminal H2 located in the external domain D2, and also 

10 service execution unit SN2 executes the service. The 
configuration shown in FIG. 15 resembles the configuration 
shown in FIG. 13. The difference between the configurations 
in FIGS. 15 and 13 lies in that, in FIG. 15, the party called 
by user host terminal HI is user host terminal H2 (call 

i-5 center) located in the other domain D2 . (In FIG. 13, user 
host terminal HI' and the called user host terminal H3 are 
existent in the same domain.) 

First, the user (service contract user) of user host 
terminal HI' operates the IP telephone function of the 
) ; terminal to originate a call by designating the opposite 
party for communication (i.e. user host terminal H2 ) (S91 
in FIG. 16 ) . 

Initiated by the user's dial operation, user host 
terminal HI' generates a service initiation message 
(SIP-invite message) designating the opposite user host 
terminal H2 , and transmits the generated service initiation 
message to the nearest service execution unit SN3 (SIP 
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server) (solid line with arrow (1) in FIG. 15, and S91 in 
FIG. 16). User host terminal HI' recognizes the location 
of the nearest SIP server in advance, and thereby the service 
initiation message is transmitted to service execution unit 
5 SN3 . 

The SIP-lnvite message transmitted from user host 
terminal HI' is received in service execution unit SN3 . 
When executing the service concerned (generation of VoIP 
session), service execution unit SN3 decides whether it 
10 is necessary to refer to the L-SPC (A) of the calling user 
host terminal HI '■ (S92 in FIG. 16). Here, in the, following: 
description, it is assumed that the L-SPC (A) is already 
retained in service execution unit SN3, and therefore it 
is decided that the further reference is unnecessary. 
15 Accordingly, the processing of a reference request for the 
L-SPC (A) to authentication server Al is omitted. 

Service execution unit SN3 transfers an SIP-lnvite 
message to service execution unit SN2 of the called user 
host terminal H2 through relay unit TS (solid line with 
20 arrow (1) in FIG; 15 ) i - ■< > 

On receipt of the SIP-lnvite message, service 
execution unit SN2 detects the service initiation, and also 
recognizes that user host terminal HI ' is managed by domain 
Dl located outside domain D2. Service execution unit SN2 
25 then decides whether the G-SPC of user host terminal HI' 
(G-SPC (A)) is to be referred to (symbol (2) in FIG. 15, 
and S93 in FIG. 16). Here, in the following description, 
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it is assumed that the reference is decided necessary. 

Based on this decision, service execution unit SN2 
generates a G-SPC request message for requesting for the 
G-SPC (A), and transmits the generated request message to 

5 authentication server A2 located in domain D2 of service 
execution unit SN2 (broken line with arrow (3) in FIG. 15, 
and S94 in FIG. 16). This G-SPC request message can also 
be transmitted by use of a Diameter message. 

From the content of the G-SPC request message, 

0 authentication server A2 recognizes this message to. be 

transferred to authentication server Al, and transfers this 
message accordingly. 

On receipt of the G-SPC request message, 
authentication server Al searches and extracts the G-SPC 
(A), and transmits the extracted G-SPC (A) to service 
execution unit SN2 through authentication server A2 , using 
a G-SPC response message (broken line with arrow (6) in 
FIG. 15, and S96 in FIG. 16). 

Authentication server A2 acquires the G-SPC (A), and 
stores the G-SPC (A) (S9 7 in FIG; 16 ) . Authentication server 
A2 then provides a service (for example, transmitting an 
advertisement message to the calling user host terminal 
HI', etc.) according to the G-SPC (A) contents. Also, 
authentication server A2 transfers the service initiation 
message to user host terminal H2, and waits for response 
from user host terminal H2 . 

By operating the terminal unit, the user of user host 



54 



terminal H2 replies to the connection request from user 
host terminal HI'. Initiated by this operation, user host 
terminal H2 transmits an SIP-Ack (acknowledgement) message 
to reply to user host terminal HI'. 
5 The SIP-Ack message transmitted by user host terminal 

H2 is forwarded to user host terminal HI' through service 
execution unit SN2 . 

When user host terminal Hi' receives the SIP-Ack 
message from user host terminal H2, the session between 
0 user host terminal HI' and user host terminal H2 is 
established. Thereafter, voice packets are interchanged 
bi-directionally between user host terminals HI ' > H3 . 

Additionally, in FIG. 15, an L-SPC (C) is the L-SPC 
of user host terminal H2 . 

As can be understood from the above description, 
according to the embodiment of the present invention, the 
SPC (L-SPC or G-SPC) specifying the user-independent 
service contents is given to a service execution unit, 
instead of an edge unit. Thus, with regard to a layer higher 
services than the layer three services , it becomes possible - 
to provide individual services for each user. 

To summarize, according to the present invention^ it 
becomes possible to provide a service customized for each 
user and for each application. 

The foregoing description of the embodiments is not 
intended to limit the invention to the particular details 
of the examples illustrated. Any suitable modification and 
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equivalents may be resorted to the scope of the invention. 
All features and advantages of the invention which fall 
within the scope of the invention are covered by the appended 
claims . 
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